I haven't found in repo history a justification for keeping this private, but if it's on purpose, I would love to know why :-)

Hmm, I'm a bit confused why this would be needed: one can add an arbitrary amount of SpanProcessors to the TracerProvider and the order will be retained - that's the same functionality, right?

Hi, yes, I want the same functionality for my custom SpanProcessor.

I have a custom SpanProcessor that transforms, augments and filter spans, and it takes a sub processor as a parameter. The transformed spans are then forwarded to this "sub-processor".

Now, I have a user that would like the spans to be passed to multiple "sub-processors", so it would be handy to use this already existing utility instead of copy-pasting the exact same logic.

I haven't made it clear, but it would be handy mainly for OTEL third party integration developers more than actual end users.

Ah, I see - since each SpanProcessor gets the same unmodified span, using the spanProcessors option when creating a TracerProvider is therefore not feasible.

I think I'd rather prefer you copying the code now. You can open an issue describing the use-case and we can see how many people would actually need it. Once we see significant interest, we can decide if we want to expose it via the public API.

A side-node: I wonder if there are any alternative ways to get the behavior you're after. Not exporting certain spans can lead to broken traces and that's usually something people try to avoid at all costs - not generating those spans in the first place is usually the safe option people choose instead. I suppose the SpanProcessor in question is this one. I don't fully understand it, but I'm wondering why the approach seems to be to re-write http spans (and drop all others) rather than just generate graphql server spans to begin with. 🤔